Day 23: 監控體系 (二)：設計 Wafer BI 專屬的監控 Dashboard

將技術指標轉化為直觀的圖表，快速掌握健康度。

1. 核心觀測指標：RED 方法論

設計 Dashboard 時採用業界常見的 RED 方法論，針對每個服務關注三件事：

• Rate：每秒請求量
• Errors：錯誤請求的比例
• Duration：請求耗時（通常看 p95 或 p99，而非平均值——平均值會被少數快請求拉低，掩蓋長尾延遲問題）

2. 建立 Dashboard

透過 Grafana API 建立一個包含四個 Panel 的儀表板：Rate、Errors、Duration、以及依 status_code 分組的總請求數。核心 PromQL：

# Rate：依路徑分組的每秒請求數
sum(rate(http_requests_total{job="kubernetes-pods"}[5m])) by (route)

# Errors：4xx/5xx 佔全部請求的比例
sum(rate(http_requests_total{status_code=~"4..|5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# Duration：p95 延遲
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

3. 用真實流量驗證

Dashboard 建好接上真實資料前，圖表全部顯示 "No data"。用 k6 對 Gateway 打真實流量後重新查看：

▲ Grafana RED Dashboard：k6 產生的真實流量下四個面板全部有資料

這張圖背後排查了兩個問題，記錄下來避免同樣的坑：

問題一：rate() 視窗太短。 Prometheus 的預設 scrape_interval 是 1 分鐘，rate(x[1m]) 這種視窗內可能只抓到 1 個樣本，rate() 需要至少 2 個樣本才能算出斜率，於是回傳空值。把視窗拉到 [5m]（至少是 scrape 間隔的 4 倍，這是 Prometheus 官方建議的下限）就正常了。

問題二：Dashboard JSON 的 target 缺少 range、instant、datasource 欄位。 透過 Grafana API 手動組 Dashboard JSON 時，這幾個欄位如果沒有明確帶入，即使直接呼叫 Prometheus API 驗證查詢完全正確，Panel 仍然會顯示 No data——因為前端沒有把它組成一個正確的 range query 送出去。透過 UI 手動建立面板不會遇到這個問題（前端會自動補齊），但用 API 建立時要自己顯式帶上：

{
  "expr": "sum(rate(http_requests_total{job=\"kubernetes-pods\"}[5m])) by (route)",
  "refId": "A",
  "range": true,
  "instant": false,
  "datasource": { "type": "prometheus", "uid": "..." }
}

4. 告警機制

monitoring/alerting-rules.yaml 定義了四條規則，用 promtool check rules 驗證語法正確後，載入實際運行的 Prometheus：

- alert: HighErrorRate
  expr: |
    sum(rate(http_requests_total{status_code=~"5.."}[5m]))
    /
    sum(rate(http_requests_total[5m]))
    > 0.05
  for: 5m
  labels: { severity: critical }

用 k6 製造高併發負載後，實際觀察 Prometheus 的 Alerts 頁面：

▲ Prometheus Alerts 頁：HighLatency 與 HighErrorRate 在真實負載下實際 Firing

HighLatency 與 HighErrorRate 都進入 Firing 狀態，PodDown 與 HighCPUUsage 維持 Inactive——這正是預期行為，因為當時沒有 Pod 掛掉，CPU 使用率的觀察屬於 Day 25 的範疇。

設計告警規則時有個地方很容易忽略：HighErrorRate 只看 5xx（伺服器端錯誤），不包含 4xx（用戶端錯誤，例如打錯路徑、缺少授權）。Day 23 的 Dashboard 裡「Errors」面板為了呈現方便同時涵蓋了 4xx 與 5xx，但告警規則刻意只抓 5xx——因為 4xx 通常代表呼叫方的問題，不代表你的服務本身故障，用同一個閾值去驚動 on-call 反而會製造告警疲勞。

5. for 欄位的作用

規則裡的 for: 5m 是防抖動 (debounce) 機制：條件成立後不會立刻觸發，要連續滿足 5 分鐘才轉為 Firing，中間會先進入 Pending 狀態。這避免瞬間的流量尖峰造成誤報，代價是真正故障發生時，也會有 5 分鐘的延遲才收到通知——閾值與 for 的設定需要在「誤報率」與「反應速度」之間取捨。

6. 小結

Dashboard 與告警規則都經過真實流量驗證，不只是語法正確、而是在實際負載下行為符合預期。明天進入分布式追蹤——當一個請求跨越 Node.js、Java、Python 三種語言時，怎麼追蹤它的完整路徑。